home *** CD-ROM | disk | FTP | other *** search
/ ETO Development Tools 1 / ETO Development Tools 1.iso / Essentials / MacApp Documentation / MacApp AppleLink Messages / MacApp.Tech$ 2⁄16⁄90 / 0653-Persistent Guerillas-Feb90 < prev    next >
Encoding:
Text File  |  1990-02-16  |  9.0 KB  |  154 lines  |  [TEXT/GEOL]
  1. Item forwarded  by  A33          to A34
  2.  
  3. Item    5735846                         12-Feb-90        19:31PST
  4.  
  5. From:   D4384                           US Voting Mach, Sarner, Calvin,PRT
  6.  
  7. To:     MACAPP.TECH$                    MacApp Technical
  8.  
  9. cc:     D5295                           Reseach SW Design, D Goldman,PRT
  10.  
  11. Sub:    Persistent Guerillas Needed
  12.  
  13. What follows is a summary of the persistent object problem in MacApp, with some
  14. possible solutions, and a proposal for guerilla tactics.
  15.  
  16.     Persistent objects may be minimally defined as objects whose state persists
  17. across invocations of an application. Traditionally, persistent data on the Mac
  18. lives in documents. But there is not yet any general purpose mechanism for
  19. treating collections of objects as documents. Such a mechanism would allow
  20. opening a document to restore all objects in the document to the state they had
  21. when the document was closed, that is the state of being fully instantiated
  22. descendents of TObject. Ideally, the methods of the classes being instantiated
  23. would also be restored, but this is not possible without more compiler and
  24. linker support than MPW provides.
  25.     Various solutions to the persistent object problem have been discussed here
  26. so far, and no doubt many others have been implemented:
  27. • Edmund noted that view resources are already a limited solution for
  28. descendents of TView.
  29. • Larry's Frameworks article presents a partial solution in the form of
  30. TStream, so long as there are not multiple references among persistent objects.
  31. Also, the entire stream must be read into memory.
  32. • Greg (me) presents a method (which Edmund happily calls virtual objects) for
  33. swapping persistent objects in and out of memory.
  34. • Someone (I've lost the link) describes keeping persistent objects on an
  35. Inside/Out database and bringing them into memory as needed.
  36.  
  37.     Each of these solutions is appropriate to its intended use, but all fall
  38. short of a general solution. A general solution would:
  39. 1)  Allow a document to be treated as a collection of persistent descendents of
  40. TObject. No special code should be needed for object I/O.
  41. 2)  Allow access to documents larger than available memory, even larger than
  42. virtual memory.
  43. 3)  Allow persistent objects to refer to other persistent objects in arbitrary
  44. networks, including cycles.
  45. 4)  Allow multiple users to have simultaneous access to the same collection of
  46. objects.
  47.  
  48. Some ideas for achieving these goals follow.
  49.  
  50. 1)  Larry's use of metadata points the way here. The main criticism of his
  51. suggestion is that we must write code for each object to support I/O. I have
  52. not found this to be so bad, as each object can INHERIT the I/O methods of its
  53. ancestors and just add in code for its new fields. But there should be a better
  54. way. It seems one solution would be to use the Fields method of each object to
  55. drive a general I/O method, as the Fields method already provides information
  56. about the types and location of each field of an object. Of course we still
  57. need to write a Fields method for each object, but we are already supposed to
  58. be doing that (not that I do!). Ideally, the compiler would generate the fields
  59. method for us.
  60.     A second issue is how to save and restore the object metadata. I would
  61. suggest that we created a resource type, similar to a view resource, for the
  62. purpose of saving the class names and field types of persistent objects. Each
  63. object on the data fork could then have in its header the ID of its class name
  64. resource.
  65.  
  66. 2)  Big documents present big problems. Virtual objects help, but require that
  67. at least a handle and a header remain in memory for each persistent object, and
  68. also require explicit locking of objects to be sure they are in memory before
  69. they are accessed. Even so, I think a general solution will include virtual
  70. objects. The idea is to keep a cache of the most active objects in memory, with
  71. less active objects being swapped out by writing their data to disk and
  72. resizing their handles down to just a small header, including the ClassID. This
  73. means that the methods of a virtual object can be dispatched whether or not the
  74. object is all in memory, but the data must be swapped in before it is
  75. referenced. Note that following the discipline of accessing object fields only
  76. through methods can largely eliminate concerns over when to swap, except for
  77. those methods themselves.
  78.     An alternative solution is to keep objects in persistent collections (such
  79. as a database) and check objects in and out of the database as needed. This is
  80. less flexible than virtual objects, but can allow for arbitrarily large
  81. collections of objects. The main restriction is that an object in a collection
  82. must be referenced only as a member of that collection, and can be a member of
  83. at most one collection at a time. Also, the database must provide support for
  84. heterogeneous collections for some typical uses of objects to be effective
  85. (such as walking a list of heterogeneous objects in a Draw method). Relational
  86. databases explicitly forbid this.
  87.     An integrated solution would allow both scalar virtual objects and objects
  88. which are in fact collections of other objects. MacApp provides only the TList
  89. type, whereas Smalltalk and others provide a rich set of collection classes. At
  90. the least a flat file, heterogeneous list, and ordered list (BTree) class could
  91. be provided, with an interface modeled on TList.
  92.  
  93. 3) References among objects are a pain, especially arbitrary networks of
  94. references. The view architecture finesses this one by requiring views to form
  95. a hierarchy that can be traversed from the root, so that references to
  96. superviews and subviews can be resolved with finite searches.
  97.     A more general solution proposed by Larry is to give each persistent object
  98. an ID (which might be their offset in the document file), refer to objects by
  99. ID, and maintain a translation table of ID's to handles. Then each  ID
  100. reference can be resolved at runtime into a handle to the object. With a
  101. virtual object scheme, this table might be created and used only while the
  102. document is being opened, and could then be disposed of.
  103.     The main problem for IDs is unresolved references. When an object is first
  104. read in its referee's IDs might not yet be in the translation table. So we
  105. might have to keep a list of unresolved references as we first traverse the
  106. document, then make a pass of this list to finally resolve them.
  107.     If virtual object IDs are implemented as file offsets then they can be
  108. resolved as they are encountered. This works OK for trees and acyclic graphs,
  109. but could cause infinite regress in the presence of cycles. Perhaps one bit of
  110. the ID caould serve to indicate whether a reference is a file offset or a
  111. resolved handle, and thus stop the regress.
  112.     The persistent collection approach allows references only to the values of
  113. objects, or their location in a collection, but never to their identity. This
  114. finesses the problem by simply not allowing direct references among objects.
  115.  
  116. 4) Multi-user access presents all the problems of data integrity and deadlock
  117. of any distributed database. Implementing persistent collections on top of an
  118. existing database is by far the easiest solution.
  119.     For virtual objects, the memory locking routines could be combined with a
  120. file range locking protocol to allow multi-user access. This would still
  121. require the programmer to prevent deadlock and maintain data integrity by
  122. careful design of access protocols (i.e. two-phase transaction locking). A
  123. really sophisticated lock manager process might be able to prevent deadlock, or
  124. at least detect it once underway, but this is usually too hard to do in
  125. general.
  126.  
  127.     In summary then, it appears that the problem of persistent objects is in
  128. need of a general solution, or class of solutions. I believe guerilla action is
  129. called for.
  130.      At the least, a simple subclass of TObject could be provided which would
  131. standardize object I/O and metadata resources. Perhaps a clipboard type could
  132. be provided as well. Beyond that, a virtual object capability could also be
  133. easily provided, preferably one that could resolve multiple references. This
  134. much alone would allow a persistent document type to be defined which could be
  135. opened by any application which defined the necessary classes. For classes
  136. which are not defined by the application at least some methods could still be
  137. supported, at least enough to make copies and extract field data.
  138.     The problems of multiple users and large collections are much harder. At
  139. least some abstract classes could be defined for interfacing to collections in
  140. databases, with access to particular databases provided by subclassing. Some
  141. simple concrete implementations would be nice, although they would probably not
  142. meet the performance needs of really big jobs (like CD-ROM). An abstract class
  143. approach might also be taken for multi-user access to virtual objects.  In this
  144. way a framework could be provided for easy sharing of data among applications,
  145. with the  most difficult, preformance critical, and application specific issues
  146. left to the capitalists to pay for.
  147.     If you have read this far I take it you are interested, so where do think
  148. we should go from here?
  149.  
  150. Yours truly,
  151.  
  152. Greg Colvin
  153.  
  154.